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(57) Abstract: The invention relates to a method and a communication system comprising at least one first network element con- 
nectable to a second network element. At least one of the first and second network elements are able to use one of two or more 
selectable modes for communicating with another network element One or both of the network elements, or a third network ele- 
ment which is connectable with the first and second network elements, is adapted to perform a mode selection procedure for selecting 
the same mode for bidirectional communication between the network elements. The modes preferably are different codec types or 
channel-coding schemes, or radio interface protocol types. The first and/or second network elements may be portable terminal equip- 
ments whereas the third network element preferably is a support node or a means providing a support function such as a CSCF. The 
mode selection ensures the use of one and the same mode such as a codec in uplink and downlink direction and thus enables e.g. IP 
telephony in UMTS using SIP protocol. 
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Communication System and Method Providing a Mode Selection 

Procedure 

FIELD OF THE INVENTION 

The present invention relates to a communication system adapted 
to perform a mode selection by selecting or negotiating the 
mode to be used. Furthermore, the invention relates to a method 
to be performed in such a communication system, and to a 
network element capable of mode selection. 

BACKGROUND OF THE INVENTION 

Communication networks transfer information such as user voice 
traffic or the like, on a packet-switched and/or circuit- 
switched basis using modes which may be commanded by the system 
or negotiated between the involved network elements such as end 
user equipments. As an example, in planned evolution of 
networks such as UMTS (Universal Mobile Telecommunication 
System) systems, additional functions and services can be 
incorporated. For instance, novel multimedia services such as 
multimedia messaging services MMS are supported within the 
system which services are IP (Internet Protocol) -based 
services. Packet-based (e.g. IP-based) service sessions such as 
multimedia service sessions may be controlled by a specific 
protocol. As an example, the Session Initiation Protocol (SIP) 
represents a protocol which may be used e.g. for call and 
connection establishment as well as for transport of endpoint 
capability information. Such capability information may e.g. 
relate to voice and multimedia codecs supported by the end 
terminals . 

The functionality . and services of such multimedia service 
systems will be mapped onto the existing network system 
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functions, e.g. of UMTS type. As an example, the system 
services may be mapped to the PDP contexts. and radio 
signalling, as well as to existing packet-switched core network 
elements and interfaces, e.g. of, UMTS type. Hence/ there is a 
5 problem of multimedia (e.g. IP multimedia) and network layer 
(e.g. GPRS layer) interactions and mapping. 

As an example, in case of VoIP calls (voice over IP-based 
connection, i.e. Internet telephony), the radio access network 

10 such as GERAN ("GSM/Edge Radio Access Network") and UTRAN (UMTS 
Terrestrial v Radio Access- Network) , may be informed on the type 
of application for deciding on the header adaptation method to 
be used for e.g. a particular PDP context. As an example, two 
different header adaptation schemes available *for selection can 

15 . for example be "header compression" and "header 

stripping/removal" . The header stripping/removal mode may be 
used for speech-only traffic where e.g. optimised speech 
transport is required for instance for integrated lower-end 
terminal devices. A header compression mode may be utilised 

20 e.g. for more general IP multimedia traffic including voice 
application operation on an external device such as a laptop 
computer connected to a UMTS phone. , 

When an inappropriate mode such as inappropriate protocol mode, 
25 header adaptation mode or radio access bearer mode should be 

selected, problems in incorrect message transmission may occur. 



30 



SUMMARY OF THE INVENTION 

The invention provides a method and system as defined in anyone 
of the claims. 

In more detail, a communication system, and/or a method to be 
performed in a. communication system, comprises at least one 
first network element, connectable to a second network element 
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via one or more packet-based networks. At least one of the 
first and second network elements provide two or more 
selectable modes for communicating with another network 
element. A mode selection procedure is performed (e.g.. by one 
5 or both of the network elements, or by a third network element 
connected to the first and second network elements), for 
selecting the same mode for bidirectional communication between 
the network elements. The selectable modes preferably are 
different codec types, or may be conversion modes of other 
10 type, or radio interface protocol types or channel-coding 
schemes etc.. 



The first and/or second network elements may be portable 
terminal equipments. The third network element preferably is a 
15 support node or support function. 

In a preferred embodiment, a protocol mainly used for other 
purposes but also capable of providing a messaging service, 
preferably an IP-based multimedia messaging service, is used 
20. for seeding information on supported or selected modes to and 
from the network elements. The protocol may be the Session 
Initiation Protocol (SIP) . SIP is a multimedia session 
establishment & control protocol, i.e. a control protocol for 
realtime multimedia. 

25 

Preferably, the network or networks connecting the first and 
second network elements is/are UMTS-based network. 

In one embodiment, the. first network element may send 
30 information on one or more modes supported by the. first network 
element to the third network element which performs the 
selection procedure and sends information on only one' or more 
than one but not all supported modes to the second network 
element which sends an acknowledgment message to the third 
35 network element confirming the support of the selected, or one 
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of the selected modes, the third network element sending a 
message to the first network element informing the latter on 
the selected mode. This is one difference between a preferred 
embodiment of the invention and the usual SIP operation. 
5 Usually there is no negotiation between the used codecs etc. 

but both elements include information on their own capabilities 
in the SIP messages. Here, a selection and a specific usage of 
the . information fields etc. is proposed. 

10 In another embodiment, the first network element may send 

information v t>n one or more modes supported by the first network 
element to the third network element which requests the second 
network element to send information on the supported modes, the 
second network element returning a list of supported modes to 

15 the third network element whereupon the third network element 
performs the selection procedure and sends messages to the 
first and second network elements informing these network 
elements on the selected mode. 

20 In a further embodiment, the first network element performs the 
selection procedure when initiating a connection to the second 
network element, and sends information on one mode supported by 
the first network element to the second network element. The 
second network element, when supporting the mode, returns an 

25 acknowledgment message, or, when not supporting the mode, 
returns a message indicating another mode supported by the 
second network element, to the first network element. The first 
network element selects this mode for further communication 
when supporting it, or, when the first network element does not 

30 support the mode indicated by the second network element 
repeats the steps a) to d) selecting another mode. -. 

In a further embodiment, the first network element, when 
initiating a connection to the second network element, sends 
35 information on all modes supported by the first network element 



4 



WO 02/15625 PCT/EP00/07932 

to the second network element. The second network element 
performs the selection procedure and returns a message 
indicating the selected mode to the first network element, 
the first and second network elements selecting the indicated 
S mode for further communication. 

The first network element and/or second network element and/or 
third network element preferably send information on the 
selected mode to a radio network control means. The information 

10 on the selected protocol mode may e.g. be sent as part of a 
negotiation procedure related to packet data convergence 
protocol, or in an Activate PDP Context message. The 
information on the selected mode preferably contains an 
additional flag indicating the application type. It is possible 

15 to send only the application type and no other information. 

The information on the selected mode preferably contains 
additional information on the header processing such as header 
compression or header stripping/removal. 

20 

Generally, in accordance with the present, invention, a 
selection procedure is provided for performing a mode 
selection, preferably when establishing a connection between 
two network elements . This mode selection such as protocol 
25 selection is ensuring that the bi-directional communication 

between the network elements is performed in a defined manner 
such as use of the same mode in uplink and downlink direction. 

As an example, such a mode selection is able to ensure that 
30 e.g. the radio access bearers in an UMTS network use and 

support the same codec type (e.g. AMR (Adaptive Multi-Rate), 
GSM FR (Full Rate), GSM EFR (Enhanced Full Rate), etc.) at the 
same time, and use the same, i.e. only one, codec type in 
uplink and downlink directions. In some cases such as AMR, 
35 there might otherwise be provided different codec modes in 
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uplink and downlink direction. The codec information may be 
used to select the appropriate radio interface protocol modes 
including an appropriate channel coding scheme for voice 
traffic. 

5 

The use of the same codec in both directions guarantees that' 
the channel coding for the corresponding radio bearer of a PDP 
(Packet Data Protocol) context is appropriately and correctly 
selected so as to be the same in both directions. As at least 
10 one PDP context is necessary for carrying the voice traffic; an 
appropriate *'radio bearer- is selected so that UMTS IP telephony 
can be performed (VoIP) without problems. 

An advantage of the invention is the possibility to enable e.g. 

15 SIP operation on top of an UMTS radio access network 

architecture and bearers. Apart from the fact that the new 
information on selected mode and application type provided to 
the radio access network is already a sort of change of the 
existing network architecture, no other changes of existing 

20 radio access networks such as UTRAN or GERAN for any actual or 
future definition such ' as 3GPP Release 2000 are necessary for 
solving the above mentioned problems. The invention therefore 
provides a solution for IP telephony on UMTS. 

25 The solution according to the invention can be implemented as a 
proprietary mechanism or function, or can be a standardised 
mechanism or function. 

In accordance with a further aspect of the invention, a network 
30 element is provided, preferably to be used in a method or 

communication system as described above, the network 'element 
being adapted to perform a selection procedure for selecting 
one of several modes supported by this or another network 
element. The modes may be different conversion modes, in 
35 particular coding/decoding modes. 
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Further aspects, advantages and details of the invention will 
be described by referring to the attached drawings which 
disclose preferred embodiments of the invention. 

BRIEF DESCRIPTION OF THE INVENTION 

Fig. 1 shows the basic structure of a first embodiment of the 
present invention; 

Fig. 2 illustrates a second embodiment of the invention; 
Fig. 3 shows another embodiment of the invention; and 
Fig. 4 illustrates a further embodiment of the invention. 

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS OF THE INVENTION 

Before describing some embodiments of the invention in more 
detail, several general aspects and features of the invention 
will be discussed. In connection set-up, some protocols such a 
the call establishment procedures of SIP (Session Initiation 
Protocol) allow negotiation and usage of several codecs from 
end-to-end, that is between the call originating element and 
the call terminating element. Further, such protocols may also 
allow the use of different codecs in uplink and downlink 
directions. Due to the selection procedure performed in 
accordance with a preferred aspect of the invention, IP 
telephony applications in networks such as UMTS of third 
generation type can be used on top of the UMTS radio access 
networks (RANs) without interfering with the functionality of 
the system and with minimum changes of the system. Hence, 
correct functioning can be ensured also in such cases. 
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When using for instance SIP, the caller, may send a set of 
supported codecs to the callee or to a third network element. 
The callee may also send a set of supported codecs to the 
caller or to the third network element. After the call-setup, 
5 when sending VoIP packets, the invention may be used to 

guarantee that the caller uses one of the codecs supported by 
the callee and the callee uses one of the codecs supported by 
the caller, and that, these used codecs are the same for the 
callee and the caller. Otherwise, when not performing a mode 
10 selection procedure for selecting e.g. only one and the sam6 
codec for tlie bidirectional communication, the sender might 
dynamically select a codec from the set of codecs supported by 
the recipient when sending data to the latter so that different 
codecs might eventually be used. Furthermore, *the used codec 
• 15 might, be different in different directions . 

In accordance with preferred implementations of the invention, 
several alternatives are disclosed. According to one aspect, a 
terminal equipment (network element) , e.g. a UMTS phone, or the 

20 network, e.g. the UMTS network, functions so as to ensure that 
always only one codec type is used in each direction, and 
further that this codec type is the same in both . directions . 
This may be achieved in one or both terminal equipments such as 
UMTS terminals by mandating support for specific codec (s) in 

25 all cases and/or by defining that only one codec can be 
announced to the other endpoint as supported codec. 

Furthermore, the behaviour of the callee is defined and adapted 
in such a manner that the call terminating equipment selects, 

30 if possible, the same codec as the one announced by the call 
originating equipment. In case of failure of the call 
terminating equipment in selecting the same codec as the one 
announced by the call originating equipment , the call 
terminating equipment is preferably adapted to select a codec 

35 which is mandatory in systems of the. third generation (3G ' 
systems), and to announce this codec to the call originating 
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equipment. The call originating equipment will support the 
announced codec as it is a mandatory one, and is adapted to 
assume at. this point that the call terminating equipment will 
use the same codec also in sending data, and will therefore 
5 adjust its behaviour accordingly. '• 

In accordance with another alternative, embodiment of the 
invention, a further solution is provided. In the network such 
as the UMTS network, a control means (third network element) 

10 will decide on the codec to be used and will handle the 

. selection procedure and the necessary messages to be sent to 
the call originating and terminating equipments. This control 
means may e.g. be the CSCF (Call State Control Function) of the 
network and/or may e.g. be the proxy CSCF in the visited 

15 network such as PLMN (Public Land Mobile Network) in case of a 
roaming subscriber, and/or the home CSCF in the home network 
e.g.- PLMN of the subscriber. 

The control means can render the decision on the codec to be 

20 used by both the call originating and terminating equipments. 
In preferred implementation, the codecs supported by the call 
originating equipment are included in a specific message such 
as the Invite message of SIP. After receiving the Invite- 
message, the control means such as CSCF can select one of the 

25 codecs, i.e. perform the mode selection procedure, and can 

modify the Invite message so as to- include only the selected 
codec before forwarding the Invite message to the call 
terminating equipment. The call terminating equipment is 
adapted to acknowledge receipt the Invite message by sending an 

30, acknowledgement message such as 200 OK message of SIP, only if 
it supports the single codec indicated in the Invite message as 
selected by the control means. It is possible to send an 
acknowledgement message also in the negative case, "e.g., giving 
negative acknowledge or including the supported codecs by the 

35 call terminating equipment.) 
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The selection procedure performed in. the control means such as 
CSCF may be based e.g. on the operator preferences. As an 
example/ when the operator prefers to use AMR, the selection 
procedure is adapted to select AMR from a set including FR, HR 
h and AMR. Another example is a case when a transcoder pool is 
used. In such a case, the operator may optimise the usage of" 
the transcoders. In the latter case, the decision and selection 
is preferably made in a control means of the visited network, 
that is in a visited network element such as e.g. in the proxy 
10 CSCF. 

Furthermore, location information of the user may be taken into 
account when deciding on the codec to be used. For example, if 
the base station subsystems (BSSs) in different parts of the 
15 network/country are e.g. based on different product releases 
and for this or other reasons prefer different codecs, or for 
reasons of transcoder pool optimisation, the codec selection 
procedure may be adapted to take account of such parameters. 

20 A further alternative approach implemented in another 

embodiment of the invention is the selection of the codec by a 
control network element such as CSCF after having received 
information on all codecs supported by the call originating 
equipment (e.g. in an Invite message) and on all codecs 

25 supported by the call terminating equipment (e.g. in the .200 OK 
message of SIP) . After having received both the messages, the 
control means knows both codec sets supported by the call 
originating equipment as well as by the call terminating 
equipment. The control means then performs the mode selection 

30 step by selecting one codec supported by both call originating 
and terminating equipments either by arbitrarily or by r 
reference to a priority list ranking the codecs according to 
the priority assigned by e.g. the network operator or service 
provider . 

35 
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After selecting the codec to be used by both call originating 
and terminating equipments, the selected codec is sent to the 
call originating equipment in a further message such as a 200 
OK message of SIP generated by modifying the 200 OK message 
S received from the call terminating equipment r and to the call 
terminating equipment in another message such as a ACK message 
of SIP. 

When the codec to be used has been selected, one or more 
10 network elements, in particular control elements such as the 
radio network controllers or base station subsystems 
controlling the . radio access to the call originating and/or 
call terminating equipment have to be informed on the selected 
codec. This informing of the network control elements can be 
15 performed in several alternative ways which are listed below in 
the preferred order. 

1. ) The call originating and/or terminating equipment such 
as a mobile station (MS) sends information on the selected 

20 codec to the radio access controller (e.g. RNC , Radio Network 
Controller) as part of the PDCP (Packet Data Convergence 
Protocol) negotiation. The messages sent to the control element 
informing the same about the selected codec may additionally 
include a separate flag or other indication to indicate the 

25 application type, and/or whether to use header compression or 
header stripping/removal for this particular PDP context. 

2. ) As an alternative, the call originating and/or 
terminating equipment sends the information on the selected 

30 codec to the serving node such as SGSN (Serving GPRS Support 
Node) . The serving node forwards the information on the 
selected codec to the control element such as RNC in the RAB 
(Radio Access Bearer) establishment request message. The 
transmitted message (s) may additionally include further 

35 information such as a flag to indicate the application type, 
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and/or whether to use header compression or stripping/removal 
for a particular PDP context. 

3.) The call state. controlling means such as CSCF may send 
information on the selected codec to the radio access control 
means such as RNC (e.g. in the following manner: CSCF -> GGSN 
(Gateway . GPRS Support Node), GGSN -> SGSN, SGSN -> RNC). As 
already stated above, the messages may also include a separate 
indication such as a flag to indicate the application type, 
and/or whether to use header compression or stripping/removal 
for the particular PDP context. 

When an application type indication (e.g. application type 
flag) is included, the information on the application type is 
transmitted from the call originating or terminating equipment 
(e.g. Mobile Station MS) or from the call control means (e.g. 
CSCF) because these entities are, in an UMTS network, the only 
entities having enough information about the services and 
applications running on top of the PDP contexts. The header 
compression is preferably set as the default operation if the 
application type is not known or indicated in the message. The 
header stripping/removal is preferably used for optimised 
speech transmission when only voice traffic is carried in the 
PDP context . 

The necessary application information is preferably received 
through internal application programming interfaces (APIs) of 
the call originating and/or terminating equipments (the 
internal APIs being arranged between the 

applications/services), the SIP layer and the UMTS /GPRS layers. 
Header stripping/removal is preferably used only in the case of 
an integrated UMTS SIP terminal. It may also be provided from a 
laptop computer to a UMTS phone in a case where the terminal 
equipment (TE) and the call originating and/or terminating 
equipments are separate devices. The application type . 
indication such as a flag may for example have the following 

12 
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explicit values: "header compression", or "header 
stripping/removal", or "application type" (e.g. value: voice) 
which indicates that stripping/removal is to be used. 

In the following/ details of a first embodiment will be 
described with reference tio Fig. 1. Fig. 1 shows a terminal, 
network element 1 which is termed "UE (User Equipment) Caller " 
and requests the establishment of a connection to another 
network element 3. The network element 3 thus represents a call 
terminating equipment and is termed "UE Callee" . The network 
comprises a further network element 2 which is a connection 
control element and is implemented as, or provides, a call 
state control function (CSCF) . When the network element 1 such 
as a MS (Mobile Station) desires to establish a connection to 
the terminal network element 3, it is adapted to send, in this 
embodiment, a message to the CSCF 2 informing the latter on the 
desire to establish a connection to the terminal equipment 
element 3 which message contains information on all codecs 
supported by the network element 1, i.e. the call originating 
equipment. This message may be an Invite message of the 
connection protocol, preferably SIP. This Invite message 
contains a list of codecs supported by network element 1. 

The CSCF element 2 is adapted to perform a mode selection 
procedure which, in this embodiment, is a codec selection 
procedure 4 selecting one of the codecs supported by equipment 
1. This codec selection 4 may be based on preference or 
priority parameters contained in CSCF 2, or may be dependent 
from the type of application desired by equipment 1 such as 
pure data transmission, pure voice over IP transmission, and 
the like. 

After performing the codec selection procedure 4, the CSCF 2 
further transmits the Invite message to the user equipment 3, 
the message now only including the codec selected by the codec 
selection procedure 4. The user equipment 3 which may likewise 
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be a mobile station or a stationary equipment, performs an 
internal check whether it supports the codec indicated in the 
received Invite message. If yes, the user equipment 3 returns 
an acknowledgement message to the CSCF 2 (preferably a 200 OK 
5 message in SIP) which message repeats the selected codec for 
confirmation of its support by user equipment 3- The CSCF 2 
transmits this acknowledgement message to the user equipment 1 
(200 OK (selected codec)) in SIP. 

10 . When receiving this message, the user equipment 1 is adapted to 
use only this indicated codec for uplink and downlink links. In 
a similar manner, user equipment 3 is adapted to use only the 
selected codec for uplink and downlink traffic, i.e. for radio 
access between user equipment 3 and the radio 'access 

15 controlling means such as RCP (Radio Network Controller). The 

radio network controllers handling the radio access to the user 
equipments 1 and 3 will likewise be informed on the selected 
codec using one of the above-mentioned methods as an example, 
and will adapt their operation mode accordingly. 

20 

When the user equipment s should not support the selected codec 
indicated in the Invite message received from CSCF 2, it is 
preferably adapted to send a message to CSCF 2 informing the 
latter on lack of support of the selected codec. Thereupon, the 

25 CSCF 2 repeats the codec selection procedure 4 but now 

selecting another codec different from the first selected 
codec, and sends this newly selected codec in a message such as 
an Invite message to user equipment s. When this codec is- 
supported by user equipment 3/ it returns the 200 OK message, 

30 otherwise the above steps are repeated until a codec is 
selected which is supported by the user equipment 3.' 

Fig. 2 shows another embodiment of the invention wherein the 
codec selection procedure 4 is performed, similar as in the 
35 first embodiment, by CSCF 2. Contrary to the above discussed 
first embodiment, the CSCF 2 requests, after receipt of an 



14 




WO 02/15625 PCT/EPOO/07932 

Invite message indicating all or at least some of the codecs 
supported by the user equipment 1, the user equipment 3 to 
return information on all codecs supported by user equipment 3. 
This message may be an Invite message of SIP defining a request 
5 for returning a list of supported codecs. The user equipment 3 
returns a message (e.g. 200 OK message of SIP) which contains a 
list of codecs supported by user equipment 3. 

This list may contain all codecs supported by user equipment 3, 
10 or may indicate only those codecs which are also supported by 
the user equipment 1. In the latter case, the user equipment 3 
receives, in the Invite message from CSCF 2, a list of the 
codecs supported by . the user equipment 1, and is adapted to 
perform a comparison of codecs supported by user equipment 1 
15 and codecs supported by user equipment 3, selecting only those 
codecs which are supported by both user equipments 1 and 3. In 
the former case in which the list returned by the user 
equipment 3 includes all supported codecs, the Invite message 
sent from CSCF 2 to the user equipment 3 may not contain any 
20 indication of codecs supported by user equipment 1. 

The CSCF 2 selects, by the codec selection procedure 4, one of. 
the codecs supported by both user equipments 1 and 3, and then 
sends messages to both user equipments 1 and 3 informing them 

25 on the selected codec for use thereof during the subsequent 

connection. The message addressed to user equipment 1 may be a 
message 200 OK of SIP indicating the selected codec. The user 
equipment 1 may return an acknowledgement message to the CSCF 2 
acknowledging the receipt of the 200 OK message and eventually 

30 repeating the selected codec. The CSCF 2 may forward the 

acknowledgement message received from user equipment 1 to user 
equipment 3 after adding (if not already included) an 
information indicating the selected codec. 

35 The embodiment of Fig. 2 contributes to a very quick selection 
of a codec supported by both user equipments. 
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All explanations, features and advantages stated above with 
regard to the first embodiment are also applicable with regard 
to this second embodiment (unless being in contradiction to the 
5 above explanations), and also for the subsequently discussed 
embodiments 3 and 4 . 

The embodiment shown in Fig. 3 is different from the above 
discussed first and second embodiment in that the codec 

10 selection procedure 4 is performed by and in the user equipment 
1. After having performed the codec selection depending on the 
intended application (voice transmission, non-real-time traffic 
or the like, or depending on other parameters, the user 
equipment 1 sends a message such as an Invite message to the 

15 user equipment 3 via the CSCF 2, indicating the selected codec. 
The user equipment 3, when supporting the selected codec, 
returns, via CSCF 2, an acknowledgement message which may be a 
200 OK message indicating the selected supported codec. 

20 In case user equipment .3 does not support the selected codec, 

the repetition of the codec selection procedure 4 including the 
transmission of the related messaging, is repeated, as already 
stated above with regard to the first embodiment (with the 
exception that the code selection procedure 4 is repeated in 

25 the user equipment 1 and not in the CSCF 2. All other 

explanations given above with regard to the first and second 
embodiments likewise apply to this third embodiment. 

Fig. 4 illustrates a fourth embodiment wherein the codec 
30 selection procedure 4 is performed. in the user equipment 3. in 
this case, the user equipment 1 sends a message, via CSCF 2, to 
the user equipment 3 indicating all codecs supported by user 
equipment 1. This message may be an Invite message of SIP. 
After having received information on the codecs supported by 
35 user equipment 1, the user equipment 3 performs the codec 

selection procedure 4 by selecting, from the list of codecs 
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supported by user equipment 1, one of the codecs which is also 
supported by user equipment 3. After having performed the codec 
selection procedure 4, the user equipment 3 sends a message to 
the user equipment 1, via the CSCF 2, informing user equipment 
1 and eventually also CSCF 2, on the selected codec. The 
selected codec is thereafter used by both user . equipments 1 and 
3. All other explanations given above with regard to the first 
to third embodiment likewise apply to the present fourth 
embodiment . 

As shown in Fig. 4 (the procedure shown in Fig. 4 is preferably 
common to all the earlier embodiments of the invention), a 
radio access controller such as RNC'5 being in charge of radio 
access control to user equipment 1 is informed by user 
equipment 1 on the selected codec, and preferably also on the 
application type; by sending an application type flag indicating 
e.g. "header compression" or "header stripping/removal". This 
information can be sent when performing the PDCP negotiation 6 
but. may also be sent in a separate message. In a similar 
.manner, the user equipments informs its radio access control 
element such as RNC 7 being in charge of radio access control 
to user equipment 3 by sending a message 8 to RNC 7. This 
message indicates the selected codec and may also contain, if 
known, an application type flag. 

This informing of the radio access control elements 5 and 7 in 
charge of the radio : access to and from the user equipments 1 
and 3, respectively, is likewise applicable to all above 
described first to third embodiments in identical manner. 

Although preferred embodiments have been, described above, the 
present invention is not limited thereto and intends to cover 
also all modifications, amendments, additions and deletions of 
features within the abilities of a skilled man. As an example, 
the mode selection procedure has been described with reference 
to the codec selection but may also consist in a conversion 
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modes selection of other type, a protocol selection procedure 
or the like . 
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5 CLAIMS 

1 • Method to be performed in a communication system 
comprising at least one first network element connectable to a 
10 second network element via one or more packet-based networks, 

at least one of the first and second network elements providing 
two or more selectable modes for communicating towards another 
network element, 

wherein a mode selection procedure is performed , the mode 
_ 15 selection procedure selecting the same mode for bidirectional 
communication between the network elements, and the mode 
selected is used in both directions in the bidirectional 
communication between the first and the second network 
elements. 

20 . 

2. A method according to claim 1, wherein the mode 
selection procedure is performed by a network element, and the 
network element performing the mode selection procedure is one 
of the following: the first network element, the second network 

25 element/ or a third network element connected to the first and 
second network elements. 

3. Method according to claim 1 or 2, wherein the 
selectable modes are different codec types. 

30 

4. Method according to claim 1, 2, or 3, wherein the 
selectable modes are radio interface protocol types. 

5. Method according to any one of the preceding claims, 
35 wherein the modes are channel-coding schemes. 
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6. Method according to any one of the preceding claims, 
wherein the first and/or second network elements are portable 
terminal equipments. 

5 7. Method according to any one of the preceding claims, 

wherein the third network element is a support node or support 
function . 

8. Method according to any one of the preceding claims, 
10 wherein a call control is used for sending information on 

supported oif selected modes to and from the network elements. 

9. Method according to claim 8, wherein the protocol 
providing the call control is the Session Initiation Protocol 

15 (SIP) . 

10. Method according to any one of the preceding claims, 
wherein the network or networks connecting the first and second 
network elements is/are a UMTS-based network. 

20 

11. Method according to any one of the preceding claims, 
wherein the first network element is sending information on one 
or more modes supported by the first network element to the 
third network element which performs the selection procedure 

25 and sends information on only one or more than . one but not all 
supported modes to the second network element which sends an 
acknowledgment message to the third network element confirming 
the support of the selected, or one of the selected modes, the 
third network element sending a message! to the first network 

30 element informing the latter on the selected mode. - 7 

12. Method according to any one of claims 1 to 10, wherein 
the first network element is sending information on one or more 
modes supported by the first network element to the third 

35 network element which, requests the second network element to 
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send information on the supported modes, the second network 
element returning a list of supported modes to the third 
network element whereupon the third network element performs 
the selection procedure and sends messages to the first and 
second network elements informing these network elements on the 
selected mode. 

13. Method according to any one of claims 1 to 10, wherein 

a) the first network element performs the selection procedure 
when initiating a connection to the second network element, and 
sends information on one mode supported by the first network 
element to the second network element, 

b) the second network element, when supporting the mode, 
returns an acknowledgment message, or, when not supporting the 
mode, returns a message indicating another mode supported by 
the second network element, to the first network element, and 

c) the first network element selects this mode for further 
communication when supporting it, or 

d) when the first network element does not support the mode 
indicated by the second network element otherwise repeating the 
steps a) to d) selecting another mode. 

14. Method according to any one of claims 1 to 10, wherein 
the first network element, when initiating a connection to the 
second network element, sends information on all modes 
supported by the first network element to the second network 
element, 

the second network element performs the selection procedure and 
returns a message indicating the selected mode to the first 
network element, 

the first and second network elements selecting the indicated 
mode for further communication. 

15. Method according to any one of the preceding claims, 
wherein the first network element and/or second network element 
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and/or third network element is sending information on the 
selected mode to a radio network control means. 



16. Method according to claim 15, wherein the information 
5 on the. selected protocol mode is sent as part of a negotiation 
procedure related to packet data convergence protocol, or in- an 
Activate PDP Context message. 

1.7. Method according to claim 15 or 16, wherein the 
10 information on the selected mode contains an additional flag 
indicating the application type. 

18. Method according to claim 15, 16, or 17, wherein the 
information on the selected protocol mode contains additional 

15 information on the header processing such as header compression 
or header stripping/removal. 

19. Communication system comprising at least one first- 
network element connectable to a second network element, at 

20 least one of the first and second network elements providing 

two or more selectable modes for communicating towards another 
network element, 

wherein the system is adapted to perform a mode selection 
procedure, the mode selection procedure selecting the same mode 

25 for bidirectional communication between the network elements, 
and the mode selected is to be used in both directions in the 
bidirectional communication between the first and the second 
network elements. 



30 20. System according to claim 19, wherein a network 

element is adapted to perform the mode selection procedure, the 
network element performing the mode selection procedure is one 
of the following: the first network element, the second network 
element, or a third netwqrk element connected to the first and 

35 second network elements. 
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21. System according to claim 19 or 20, wherein the modes 
are different codec types or channel-coding schemes, or radio 
interface protocol types. 

b ■ . ■ ■ 

22. System according to claim 19, 20 or 21, wherein the 
first and/or second network elements are portable terminal 
equipments . 

10 23. System according to any one of claims 19 to 22, 

wherein the third network element is a support node or a means 
providing a support function. 

24. System according to any one of claims 19 to 23, 

15 wherein a network or networks connecting the first and second 
network elements is/are a packet-based network, preferably 
UMTS-based network. 

25. System according to any one of claims 19 to 24, 
20 wherein the first" network element is adapted to send 

information on one or more protocol modes supported by the 
first network element to the third network element which is 
adapted to perform the selection procedure and to send 
information on only one or more than one but not all supported 

2 5 protocol modes to the second network element, the latter being 
adapted to send an acknowledgment message to the third network 
element confirming the support of the selected, or one of the 
selected protocol modes, the third network element being 
adapted to send a message to the first network element 

30 informing the latter on the selected protocol mode. 

26. System according to any one of claims 19 to 24, 
wherein the first network element is adapted to send 
information on one or more protocol modes supported by the 

35 first network element to the third network element which is 
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adapted to request the second network element to send 
information on the supported protocol modes, the second network 
element being adapted to return a list of supported protocol 
modes to the third network element whereupon the third network 
element is adapted to perform the selection procedure and to 
send messages to the first and second network elements 
informing these network elements on the selected protocol mode. 

27. System according to any one of claims 19 to 24, 
wherein 

a) the first - network element is adapted to perform the 
selection procedure when initiating a connection to the second 
network element, and to send information on one mode supported 
by the first network element to the second network element, 

b) the second network element being adapted to return, when 
supporting the mode, an acknowledgment message, or, when not 
supporting the mode, to return a message indicating another 
mode supported by the second network element, to the first 
network element, and 

c) the first network element being adapted to select this mode 
for further communication when supporting it, or, 

d) when the first network element does not support the mode 
indicated by the second network element, the system being 
adapted to repeat the steps a) to d) selecting another mode. 

28. System according to any one of claims 19 to 24, 
wherein 

a) the first network element is adapted to send, when 
initiating a connection to the second network element, 
information on all modes supported by the first netwprk element 
to the second network element, 

b) the second network element being adapted to perform the 
selection procedure and to return a message indicating the 
selected mode to the first network element, 

the first and second network elements being adapted to use the 
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indicated mode for further communication. 

29. System according to any one of claims 19 to 28, 
wherein the system is adapted to use a call control protocol 
for sending information on supported or selected modes to and 
from the network elements* 

30. System according to claim 29, wherein the protocol is 
the Session Initiating Protocol (SIP) . 

31. System according to any one of claims 19 to 30, 
wherein the first network element and/or second network element 
and/or third network element is adapted to send information on 
the selected mode to a radio network control means. 

32. System according to claim 31, being adapted to send 
the information on the selected mode as part of a negotiation 
procedure related to packet data convergence protocol, or in an 
Activate PDP Context message. 

33. System according to claim 31 or 32, wherein the 
information on the selected mode contains an additional flag 
indicating the application type. 

34 . System according to claim, 31, . 32, or 33, wherein the 
information on the selected mode contains additional 
information on the header processing such as header compression 
or header stripping/removal. 

35. Network element , preferably to be used in a method as 
defined in any one of the claims 1 to 18, or in a communication 
system as defined in any one of claims 19 to 34, the network 
element being adapted to perform a selection procedure for 
selecting one of several modes supported by this or another 
network element. 
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36. Network element according to claim 35, wherein the 
modes are different conversion modes, in particular 
coding/decoding modes. 
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